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Abstract We introduce the temporal logic Jeagle and its supporting tool for run- 
time verification of Java programs. A monitor for an Jeagle formula checks if a 
finite trace of program events satisfies the formula. Jeagle is a programming ori- 
ented extension of die rule-based powerful Eagle logic that has been shown to be 
capable of defining and implementing a range of finite trace monitoring logics, 
including future and past time temporal logic, real-time and metric temporal log- 
ics, interval logics, forms of quantified temporal logics, and so on. Monitoring is 
achieved on a state-by-state basis avoiding any need to store the input trace. Jeagle 
extends Eagle with constructs for capturing parameterized program events such 
as method calls and method returns. Parameters can be the objects that methods 
are called upon, arguments to methods, and return values. Jeagle allows one to 
refer to these in formulas. The tool performs automated program instrumentation 
using AspectJ. We show the transformational semantics of Jeagle. 

1 Introduction 

Model Checking [6], Theorem Proving [14] and Static Analysis [16] are techniques 
aimin g at static program verifi cation. The fi rst is concerned with checking if all pos- 
sible traces derived from a program (or abstract model) satisfy a property of interest. 
The state-space explosion is known to be an issue when considering concurrency and 
unbounded types. Additional model abstraction, such as partial-order reduction, can 
reduce the model size considerably but scalability is still an issue when checking prop- 
erties of programs in general. Theorem Proving relies on the language semantics and 
a proof system in order to come up with a proof that the system will behave correctly 
for all possible inputs. The proof system can be defi ned inductively on the syntax of 
the program. This technique requires user ingenuity to produce checkable predicates. 
For instance, there are valid properties which are non-inductive. That is, can not be 
proved valid using induction on the syntax. In practice, only reachable program states 
must satisfy stated properties. In order to cope with non-inductive properties, the user 
may start by specifying a high-level property and then providing more information to 
prune the set of possible transitions. This technique is thus not fully mechanizable . That 
is, it requires user intervention. As yet another technique, static analysis is concerned 
with analyzing the program offline and generating summarized information about its 
elements. The outcome of the analysis is usually imprecise but can be interpreted con- 
servatively to produce program transformers that can, for example, optimize the code 
or simplify it with respect to some property that wants to be observed. 
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In contrast to these techniques, this paper describes a logic and tool that employs 
dynamic analysis to detect bugs in software during its execution* Runtime Verifi cation 
(RV) [1] is concerned with checking a single trace of the program against properties 
described in some logic. When a property is violated or validated the program can take 
actions to deal with it. The technique scales since just one model is considered. In 
addition, since the check is done during runtime only reachable states are touched. The 
technique can be used both for testing and monitoring. In the fi rst case, one must come 
up with test cases [2] that might exercise a bug. In this setting RV is considered as an 
auxiliary tool to automate the creation of oracles that detect errors. An RV tool can also 
be used to monitor a program run so to take actions in response to the violation of a 
property. Under this perspective the RV tool may be used to defi ne how the program 
reacts to bugs, possibly steering it to the correct behavior [8]. 

The paper describes a logic and its tools, named JEAGLE, for runtime verifi cation 
of Java programs. By using a dialect of Java, the user can describe temporal proper- 
ties relating different points in the program and their accessible objects, and verify the 
program against these properties during runtime. The logic is defi ned on top of Eagle 
which is more expressive than several logics [3]. Eagle not only allows one to state 
temporal, and interval properties but also to defi ne new logics. 

Instrumentation is acknowledged as an issue that runtime verifi cation tools have to 
face in order to monitor programs [5, 13, 10]. Some tools provide no support for me- 
chanical instrumentation, others use annotations in the source program to check against 
verifi cation formulae. We understand that automated instrumentation is part of the prob- 
lem we want to solve, and that a tight integration between the logic and the source lan- 
guage will not only simplify the task of writing and reasoning about properties but also 
give opportunity to mechanical instrumentation. 

We claim that by augmenting the Eagle language with a simple construct that al- 
lows one to bind da t a values from parameterized events of the program is a way of 
achieving this goal. This construct is the event expression and has been mainly influ- 
enced by aspect languages [12] and process algebras [15]. 

We present related work in the following section. In section 3 Eagle is described. 
Section 4 presents JEAGLE as an extension to Eagle. It first describes the tool; the 
language syntax and monitor examples are then given. Finally, a transformational se- 
mantics is defi ned and the implementation discussed. Section 5 concludes this work. 

2 Related Work 

Eagle [3] is a language-independent runtime verifi cation tool and logic. It requires 
the user to create a projection of the actual program state. User-defi ned formulae are 
evaluated with respect to this projected state. The Eagle language essentially extends 
the /i-calculus with data parameterization. JEAGLE is defi ned on top of Eagle and 
supports automated instrumentation and object reasoning in the expense of making the 
language specifi c to Java. 

JAVA MaC [13] defines an event-based language to describe monitors. MaC is 
comprised of two specifi cation languages, PEDL and MEDL. The fi rst is tightly inte- 
grated to the programming language and defi nes events that might occur during the pro- 
gram execution. A MEDL specifi cation, on the other hand, makes use of these events 
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in order to state high-level requirements. JEAGLE can defi ne MaC conditions as rules 
and local variables can be cast as formal parameters in these rules. In contrast to MaC 
that allows user-defi ned high-level events to be described, Jeagle event expressions 
only concern method calls and returns currently. However, this construct is designed to 
be extensible so to allow one to reason about other program events. In addition, Jeagle 
supports data binding and object reasoning which we believe to be an essential feature 
of object-oriented program monitoring. To the best of our knowledge MaC does not 
support them. 

Jass [4] is a Java tool providing a trace-assertion checker in addition to a language 
for describing pre and post conditions for methods, loop variants (used to assure loop 
termination) and invariants, and class invariants which are predicates about the state of 
objects of a particular class. These are defi ned in a similar fashion as in Eiffel [19]. 
The language of trace-assertions is similar to CSP and interests us the most. Trace 
assertions are defi ned as class invariants in the form of annotations in the class fi le. The 
notation and semantics of the data-binding construct is similar to those used in modal 
logics for process-algebras like CCS and 7t-calculus [15]. These works influenced us 
severely on the integration of program and logic as well as on the notation and semantics 
of event expressions. We understand that the distinction between JaSS and JEAGLE rely 
mainly on the expressiveness of their language. For example, Jeagle do not provide 
built-in operators for parallel composition and hiding and this could make the set of 
possible traces easier to defi ne. 

Temporal Rover [7] allows the user specify LTL requirements to be checked 
during runtime. The programmer needs to manually instrument the program in order to 
emit events to the checker. Similarly to Temporal Rover, Jeagle supports LTL with 
past and future combined. In contrast, Jeagle provides automated program instrumen- 
tation, can capture data via events of different points in the program, and allows one to 
write specifi cations in different logics. 

MOP [5] is a methodology and framework for building program monitors. In MOP 
the craft of a monitoring tool is divided into building a logic engine and a logic plu- 
gin. The fi rst is concerned with generating a software artifact that will check the trace. 
The later is concerned with the integration of the target program and the logic engine. 
Instrumentation and EDE integration are supported by the engine. Several plugins have 
been created in this line already including those for ERE and LTL. We believe Jeagle 
can be defi ned in MOP as well. 

3 The Eagle Logic 

In this section, the Eagle fi nite-trace monitoring logic is introduced. This section as 
well as the Appendix A are modifi cations of part of [3] and serve to give background 
on Eagle. 

Eagle offers a succinct but powerful set of primitives, essentially supporting re- 
cursive parameterized equations, with a minimal/maximal fi x-point semantics together 
with three temporal operators: next-time, previous-time, and concatenation. The next- 
time and previous-time operators can be used for defi ning future and past time logics on 
top of Eagle. The concatenation operator can be used to defi ne interval logics and ex- 
tended regular expressions. Rules can be parameterized with formulas and data, which 
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allows the defi nition of new combinators and contexts to be captured in different points 
in time. 

Atomic propositions are boolean expressions over a user-defined object denoting 
the current state of the program. This design decision allows one to monitor programs 
written in different languages with reduced effort. That is, one needs to defi ne such 
state object in Java, which is the Eagle implementation language, and send events to 
it in order to keep it updated. The logic is fi rst introduced informally by means of two 
examples. Syntax and semantics are given in Appendix A. 

3.1 Eagle by example 

Assume we want to state a property about a program P, which contains the declaration 
of two integer variables x and y. We want to state that whenever x is positive then even- 
tually y becomes positive. The property can be written as follows in classical future time 
LTL: □(x>0-^0y>0). The formulas QF (meaning “ always F”) and OF (meaning 
“ eventually F”), for some property F, usually satisfy the following congruences [14], 
where the temporal operator QF stands for next F (meaning “m next state F”): 

QF = F A Q(DF) 0 FsFV 0(0 F) 

One can, for example, show that QF is a solution to the recursive equation X—F A QX ; 
in fact it is the maximal solution 3 . A fundamental idea in Eagle is to support this kind 
of recursive defi nition, and to enable users to defi ne their own temporal combinators 
using equations similar to those above. In this framework one can write the following 
defi nitions for the combinators Always and Eventually, and the formula to be moni- 
tored (Mi): 

max Always ( Form F) — F A (^Always (F) 

min Eventual ly ( Form F) = F V OEventually(F) 

mon Mi = Always (jc > 0 — > Eventual ly(y > 0)) 

The Always operator is defi ned as having a maximal fi x-point interpretation. That is, 
if by the end of the trace the property was not yet violated it is assumed to be val- 
idated. On the other hand, the Eventually operator is defined as having a minimal 
interpretation. If by the end of the trace the formula was not yet validated the eventu- 
ality is considered violated. Maximal rules defi ne safety properties (nothing bad ever 
happens), while minimal rules defi ne liveness properties (something good eventually 
happens). In Eagle, the difference only becomes important when evaluating formulas 
at the boundaries of a trace. To understand how this works it suffi ces to say here that 
monitored rules evolve as new states appears in the trace. Assume that the end of the 
trace has been reached (we are beyond the last state) and a monitored formula F has 
evolved to F f . Then all rule applications in F' of maximal fi x-point interpretation will 
evaluate to true, since they represent safety properties that apparently have been satis- 
fi-ed throughout the trace, while applications of minimal fi x-point rules will evaluate to 
false, indicating that some event (fid not happen. Assume for example that we evaluate 
the formula Mi in a state where x > 0 and y < 0, then as a liveness obligation for the 

3 Similarly, OF is a minimal solution to the recursive equation X = F V QX 
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future we will have the expression: 

Eventually (y > 0) A Always (x > 0 — ► Eventual ly(y >0)) 

Assume that, at this point, we detect the end of the trace. That is, we are beyond the last 
state. The outstanding liveness obligation Eventually (y > 0) has not yet been fulfi lied, 
which is an error. This is captured by the evaluation of the minimal fi x-point combinator 
Eventually being false at this point The obligation corresponding to the right-hand 
side of the A, namely, Always (jc> 0 — ► Eventually(y>0)), is a safety property and 
evaluates to true. 

For completeness we provide remaining defi nitions of the future time LTL operators 
Z1 (until) and (unless) below, and also the past-time operator S (since) used in an 
example later on. Note how Unless is defi ned in terms of other operators. However, it 
could have been defi ned recursively. 

min Until ( Form FT Form Ft) = Fz V (Fi A 0 Unt il(ft ? ft)) 
max Unless ( Form F \ , Form Fz) = Unt il (F\ , ft) V Always (F\ ) 
min Since ( Form Fj , Form Ft) — Fz V (Fi A Q Since(Fi , F 2 )) 


Data Parameters 

We have seen how rules can be parameterized with formulas. Let us modify the above 
example to include data parameters. Suppose we want to state the property: “whenever 
at some point ix~k) > 0 for some k y then eventually y = k”. This can be expressed as 
follows in quantifi ed LTL: D(x > 0 -+ 3£.(x = k A 0y = *))• We use a parameterized 
rule to state this property, capturing the value of x when x > 0 as a rule parameter. 

min Rfint k) — Eventually (y = k) mon Mz = Always (x > 0 — ► R(x)) 

Rule R is parameterized with an integer k, and is instantiated in Mz when x > 0, hence 
capturing the value of x at that moment. Rule R replaces the existential quantifi er. The 
logic also provides a previous-time operator, which allows us to defi ne past time opera- 
tors. Data parameterization is also used to elegantly model real-time logics. The syntax 
and semantics of Eagle is defi ned in Appendix A. See [3] for more details on Eagle 
and how to encode LTL, MTL in the language. The textual notations for Q and Q in 
Eagle are respectively @ and #. 

3.2 The Eagle tool 

Eagle monitors and rules are specifi ed in a text fi le. In order to verify the program 
against the stated properties, the programmer must instrument the application in points 
affecting any formula in the specifi cation. In the example above, at any place where x 
and y are updated. In these points, the Eagle state must be updated and then the for- 
mula verifi ed as fi gure 1 shows. Straight lines denote events sent from the instrumented 
program. 

When an instrumentation point is hit the Eagle state is updated (1). Then, the observer 
corresponding to the specifi ed properties (spec) is notifi ed (2). In response, the observer 
evaluates the formulae in the current state (3) and derive new obligations for the future 
which are stored in its internal state. 
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Fig. 1. Eagle architecture 


4 JEAGLE 

Jeagle is a logic and tool for runtime verifi cation of Java programs. It is built on top 
of Eagle. That is, monitors defi ned in this language are translated to Eagle moni- 
tors. Because of this, we claim that Jeagle is not more expressive than Eagle. On 
the one hand, the logic Jeagle aims at providing a more concise syntax for writing 
object-oriented temporal specifi cations. On the other hand, the tool automates program 
instrumentation and the generation of Eagle monitors therefore reducing errors and 
programming effort. 

In the previous examples x and y are fi elds declared in the Eagle state. In Eagle, 
this state is all the observer class can access (see fi gure 1). In Eagle it is not possible 
to write, directly in the specifi cation fi le, properties about program objects and how 
they interact. In order to achieve this, one needs to insert (or update) such objects in the 
Eagle state whenever an event of interest takes place; and create rules denoting the 
scope of these objects, as R in M2. These tasks are time-consuming and error-prone. 

The Jeagle language allows the user to reason about program objects rather than 
this artifi cial state. That is, the user is able to refer to the program state directly not 
through a possibly inaccurate projection of it. This is realized through events. In prac- 
tice, the user is able to declare interest in program events and these can cany references 
to objects that are subject to reasoning. 

Jeagle extends the Eagle language with Java expressions and with a construct 
hereafter called event expression. This construct has been mainly inspired by modal 
logic and aspect languages. 


Jeagle in runtime 

Ehiring program execution the state contains information about the most recent event 
emitted which is also declared in the specifi cation. We create Aspect! aspects [12] to 
track events that occur in the formulae and update the sjate. 

Some methods declared in the state check if an event has occurred. These methods 
are called from the observer to decide if the state satisfi es the (event) guard of an event 
expression. In practice, whenever a program point of interest is hit, the Eagle state 
gets updated and the formulae are checked by the observer. 
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4.1 Syntax and Informal Semantics 

The syntax of JEAGLE is defi ned in fi gure 2. This is a simplifi cation of a grammar 
defi ned in a JLex/Java CUP [11] specif cation. 

Event expressions take the form: [event] assertion and (event) assert ion, and 
extend the language of boolean propositions. So far events correspond to a method being 
called or returning from and may bind variables in the scope of an Jeagle assertion. 
Question marks are used within the event description for this purpose. In addition, the 
construct has an implicative semantics, and a conjunctive semantics. 

Therefore, [e] false means that e must not occur while (e) true means that e must occur. 

A transformation system is formally defi ned in the next section. The semantics of 
JEAGLE can be inferred by interpreting the rules of this system. However, the seman- 
tics is very detailed. Therefore, we understand it is still worth showing the informal 
semantics of the event expression. We use a functional pseudo-language in this attempt. 

Informal semantics of an event expression 

In what follows we show the semantics of an event expression whose event is associated 
to a method call. Note that other events are possible to be defi ned: 


[f [eaglepp-method-expression: ev] eaglepp-expr. epp ]3 = [[ 


if ev_ then 

let { (x,y) | y? € FV{ev) A x £ FV(epp) } in 
epp [xVy] 
else true 

]] 


ev_ is a predicate that is valid when an event associated to the method call eagleppjne 
thod ^expression occurs, and [ it /~yt] denotes the sequence of substitutions [x\ /y\ 3 — 

[, x n /y n ] over the pairs in the binding set Note that y is an ideqtifi er occurring 

free in ev and labeled with a question mark, and x does not occur free in epp. That is, 
it is a fresh name. 

Expressions defi ned inside brackets are not evaluated. The program will be instru- 
mented to track the events associated to them. When the event triggers, the expression 
that follows the bracket (epp) is evaluated in the extended environment. The other forms 
of event expression have similar semantics with identifi ers labeled with question marks 
possibly binding the calling thread or the result of a method. 
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annotation ::= defi no block monitor. seq 
monitorseq monitorseq monitor \ monitor 
monitor ::= mon Id = eaglepp.expr . 
dot i no block ::= var Id Id ; defi ne block | 6 
eaglepp.expr ::= [ eaglepp.event.expression ] eagiepp.expr 

| < eaglepp.evenLexpression > eaglepp.expr 
| javaJxx>lean.expr 
| Id ( eaglepp.expr^eq ) 

| eaglepp.expr prop-bop eaglepp.expr 

| ( eaglepp.expr ) 

| " eaglepp.expr | # eagleppexpr \ @ eagleppexpr 

eaglepp-exprseq eaglepp.expr , eaglepp-exprseq | s 

eaglepp.evenLexpression eaglepp.even Lexpression.thread 

| eaglepp.evenLexpression^iothread 

eaglepp.even Lexpressi on-thread ::= Id?! : eaglepp.even Lexpressionmothread 
eaglepp.event.expressionmothread ::= eaglepp-methotLexpression returns 

| eaglepp-methocLexpression returns Id ?! 

[ eaglepp-method-expression 

eaglepp-methocLexpression ::= Id?! . Id ( paramJist ) 
paramJist Id?! } paramJist | e 
java.boolean.expr java.boolean.expr rop java.boolean.expr 
| java.boolean.expr && java.boolean.expr 
| java.boolean. expr || javaJxx>lean.expr 
| a Java method expression 

| ! java.boolean.expr | ( java.boolean.expr ) | Id 
prop-bop ::= V | A | — ► 

rop::=<= | < | > | >= | == 

Id?! ::= Id? \ Id 

Id a Java identifier 

Id? Id ? 


Fig. 2. Subset of the JEAGLE grammar 
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4.2 Jeagle by Example 
Temporal Buffer Requirements 


observer BufferMonitor { 

var Buffer b ; 
var Object o ; 

mon MO = 

Always { [b?.put(o?)3 Eventually ( <b.get{) returns k?> k == o ) ) . 
mon Ml = 

Always ( [b?.put(o?)3 @ ( Always ( [b. put (o) ] false } ) ) • 

} 


Monitor MO states a property that all buffers must be empty by the end of the trace, 
while monitor Ml states that an object can not be added to any buffer more than once. 
The eventuality of MO can also be expressed as: <b . get ( ) returns o>true. 

Note that we assume events to be disjoint. That is, two events do not occur simulta- 
neously. In other words, events have an interleaving semantics. In addition, recall that 
formulae are interpreted as data unless they have to be evaluated in the current state. 

Strict Alternation in acquire and release of Locks 

The monitors M2 and M3 below state that there should not be an acquire of a lock without 
a future release, and there should not be a release without a past acquire. The term “t? 
qualifi es the event description with the thread from which the event was sent. 

observer FiieSystemMonitor { 

var Thread t ; 
var FileSystem fs ; 
var int 1 ; 

mon M2 = 

Always ( [t? : fs?.acquireLock(l?) ] @ ( 

Until ([t: fs.acquireLock(l) ] false, <t: fs.releaseLock(l) >true) ) ) . I 

mon M3 = 

Always ( [t? : fs? .releaseLock(l?) ] # { 

Since ( [ t : fs.releaseLock{l} ] false , <t: fs.acquireLock{l)>true) ) ) . 

} 


The fi rst requirement detects a missing release that could lead to starvation and deadlock 
since other threads could depend on this lock. The second detects the release of a lock 
whose current thread does not own. 
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43 Transformation Rules 


JEAGLE specifi cations are translated into Eagle monitors and instrumentation arti- 
facts. Three components need to be produced out of an JEAGLE specifi cation: (1) An 
aspect in the ASPECTJ [12] language that will instrument the program to emit events 
associated to event expressions, (2) the Eagle state (as described in section 3.2), and 
(3) standard Eagle monitors and rules corresponding to the JEAGLE requirements. 

We now describe a subset of the transformation semantics for JEAGLE as a set of 
axioms and rules over the relation o C Con fig x Con fig, where Con fig = Tx^x 
Jlxjx Term , defi ned as follows: 

- T is the type environment that is carried over in order to type methods that will be 
generated 

- !AC is the set of natural numbers. This item is used to generate fresh identifi ers. 

- <B denotes an environment qualifying names that occur in event expressions with 
attributes that we associate with some runtime abstraction, e.g. “the fi rst argument 
of method m’\ denotes a function Id — + ( keywords U Id ). Keywords represent 
data values captured in the last event notifi ed by the program run. For example, the 
event b? .put ( o? ) adds the pairs [b »-+ caller] and [o »— ► argl] to the map. Note that 
the mappings above are only valid until the next event arrives. The mappings of b 
and o are replaced by the identity when a rule binding these names is created. 

- denotes the set of rules to be added to the resulting Eagle specifi cation. Each 

rule has the form: where R n is a name identifying the rule, ^ is a list 

of (name x type) denoting the formats, and t is the rule body. 

- A is the set of aspect pointcuts and advices [12] for program instrumentation. 

- S is the set of methods that need to be defi ned in the Eagle State class. This is 
the only way standard Eagle can access data values from the formula. 

- Term — (J L(k), where £ is a syntactic category in the grammar defi ned. Term 
corresponds to the union of the languages defi ned by each JEAGLE connected com- 
ponent. 

Assume the following variables: ev denotes an esLgleppxvent expression, epp an eaglepp , 
expression , eppseq an eagleppjexprseq. t denotes a Term, tseq a Term Sequence, y a 
type environment, n a natural number, b a name environment, r a set of rules, a a set 
of aspects, s denotes a set of method declarations, and id an Id These names denote 
different variables when appearing primed or with a number suffi x. 

[Event expression ]: 


',n,b,r,a,s,ev) > (y^b'^a'^t) 

r 7 n,b // ,r,a / ,s / ,epp) > (y^b/^",^) 

(y,n,b,r,a,s,[ev]epp) > (y,n',b S[R n *- (^,t')],a",s /, J t -+*„(**)) 

The following applies to the variables in the rule: ri = n + 1, ** is a sequence of the form 
<..., getValue (b’(k)),...>, and is a sequence of the form <...,(k,y(k)),...> where k 
€ FV (ev) n Id?. In other words, k is a free identifi er labeled with a question mark, 
declared in ev, and possibly used in epp. The rule call R n (Tt) defi nes a new scope in 
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which these identifi ers are bound. The binding map b’ gives the keywords to each k , 
and y their types. getValue is the name of a method in the JEAGLE state that will be 
used to access the objects denoting these keywords. Note that a different map (b”) is 
carried over to transform epp. This happens because the identifi ers are already bound 
in the rule R n . So b” equals to b with [k k] for all k € FK(ev) Pi Id?, b’ and b” are 
discarded after the transformation. 

The event expression has similar semantics. They differ in the final term 
produced. Instead of t — ► R n (it) this construct produces the term t A R n (lt). 

[Rule Application]: 


(Y,n,b,r,a,s,eppseq) > foibb/^'^tseq) 

(Y,n,b,r,a,s,idO(eppseq)) > ( Y ,n,b/^^idO(tseq)) 

meaning that the transformation of a rule application depends only on its actual param- 
eters. The rule for JEAGLE expression sequence follows: 

(Y,nO,b,r,a,s,epp) t> (Y,nl,b,rV,s',t) 

(Y^nl^r^a'^epp-seq) E> (Y,n2,b 1 i /f ,a",s",t / ) 

(Y, nO,b,r,a,s, epp “”epp seq) > (Y,n2,b,r / Ur / ',a / Ua",S / Us", t ts) 

[Event binding all variables (example)]: 

One can defi ne events of many forms and each may bind variables differently. We de- 
cided to fi x the format of an event in order to make clear the use and defi nition of 
bindings. The next two transformations are instantiations of the ‘Event” transformation 
axiom (not showed). 

We here defi ne the translation of events denoting “method returns” in which the 
issuing thread, arguments, result, and target object are all passed as parameters to the 
rule that defi nes the continuing obligation. That is, all identifi ers in the event are binding 
(appear labeled by a question mark). 


(Y,n,b,r,a,s, IdO? : idl?.id2.(plist) returns id3?) > (Y,n / ,b / ,r,a / ,s / ,id # i()) 

In this transformation ri = n + 1, idO denotes the thread name, idl the calling object, 
id2 the method name, and id3 the name of the returned value. This event is translated to 
a boolean expression (id n ()) retailing true when the declared event is the current event 
notifi ed in the Eagle state. In addition to this, the name environment must be updated 
as well as the aspect and set of state methods: 

b’ = b \ {[pi *-► arg ,] | p x = headCtail^pIist)) and pi G Id? and 0 < i < |plist|) \ 

{ [idl •-+ caller], [id3 «-* return], [idO issuingThread] }. The symbol \ denotes right over- 
riding of bindings as usual. 

a* = a U “pointcut to track returns of method id2 passing the calling thread, call target, 
return value, and parameters as arguments to a corresponding advice”. 

s’ = sU{“ public boolean id„ ( ) { ... } ” }, where id„ is a fresh identifi er. This 
method denotes an event that will be used in the Eagle formula corresponding to 
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the event expression associated to this event. The event denoted by “t : a .m ( i? , j ) 
returns o?” drives the generation of a method that will return true when the caller 
is a, the method called is m with parameters as defined by y(i) and y(y), the second 
argument of the call is j, and the calling thread is t. 

[Jeagle Event using bound variables (example)]: 

The previous rule and this differ essentially in how they build the aspect and the method 
denoting the event. These constructions are described by a’ and s\ n’ = n + 1: 


(y,n,b,r,a,s, idO : idl.id2.(plist) returns id3) > (y,n',b,r, a', s', id n (^)) 
a’ = aU “pointcut and advice to track returns of method id2. 

s’ = sU{“ public boolean id n ){ ... } ” }, where id n is a fresh identifi er. This 
method returns true when the last event tracked with an aspect advice has idO as the is- 
suing thread, idl as the calling object, and so forth. These identifi ed variables are passed 
as parameters C]t) to id„() while the last event is part of the EaGLE global state. 

■j? is a sequence of the form 4 : <. . fc. . . >, where k € FV(“idO : idl . id2 . ( plist ) 
returns id3”) Pi (b < Id). Since all names appear without question marks there must 
be an enclosing rule in which these names bind formal parameters. This is checked by 
intersecting the set of names with (b < Id). 

[Java Boolean Expression]: 

(y,n,b,r,a,s,bexp) d> (y,^b,r,a,sf ,id„( x>)) 

s’ = su{“ public boolean id„ ( ~j? ) { bexp } ” }. Java boolean expressions are 
translated into boolean methods that can be used as predicates in the generated Eagle 
formula. Note that no transformation is applied within the Java boolean expression 
since the syntax of these are closed in the Java language (see section 4.1). 

The method call construction is as defi ned in the previous rule and thus omitted. In 
addition, ri = n + 1. 

[Monitor]: 


(y,0,b,r,a,s,epp) > (y,n,b,r / ,a / ,s / ,t) 

(y,O 7 0,0,0,0,mon idO = epp) > (y,n J 0,r , J a , ,s / J t) 

We omitt the rules for the defi ne block since it is only associating names to type. Note 
that no new term is generated particularly in this rule. The Eagle expression can be 
output as the concatenation of all rules collected (r’) and a monitor of the form: 

mon id„ = t . 

Similarly, the aspects can be generated from a’ and the state from s’. 

4 In the general ‘Event” transformation It = it ^ ■ It 2 where the first sequence is in charge of 
passing the values bound by names with question marks, and second sequence takes the form 
defined here. 
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4.4 Buffer Example revisited 

Figure 3 depicts the format of a logic observer specifi cation in JEAGLE for a Buffer 
monitor defi ned in the beginning of this section. The transformation of this specifi ca- 
tion produces the following Eagle monitor and rules: max R2 (Object o. Object k) = 

compare_references (o, k) . 

max Rl(Object b, Object o) =Eventually{get_{b} AR2 (o, getValue(ht, ' 'return' ') ) . 
mon Ml = Always (put_ ( ) — ► Rl (getValue (ht , ' ' caller 7 ' ) , getValue {ht , ' ' argl ' ' ) ) . 

We changed the name of the methods (to get- ( ) , put- ( ) , compare-references ( ) ) 
to improve understanding. These are declared in the Eagle state. 


...Eagle specification file with additional rules and monitors 

observer Buf ferObserver { 

classpath = C: /downloads/src 
targetPath = C: /downloads/src 
tenninationMethod = buf ferexample. Barrier .end {) 

var Buffer b ; 
var Object o ; 
var Object k ; 

mon Ml = Always! ib?.put(o?)] 

Eventually ( <b.get() returns k?> (o == k) ) } . 


Fig. 3. JEAGLE observer 


ht is a hash table stored in the state and carried over to access the parameters of the 
last event. This is necessary because methods declared in the Eagle state and called 
from the observer (corresponding to the specifi cation above) can only access actual 
parameters. So we have to pass a table that maps keywords to their associated objects 
in the latest event. 

Note that rules have Object as formals. This is not relevant because an Eagle 
observer makes reflective calls to a state method assuming it has the formal types equal 
to the actual types of the arguments. We regard these as Eagle implementation issues 
so they have been omitted thus far. 

4.5 Implementation 

A parser for JEAGLE was built using JLEX and Java CUP. Each transformation rule 
or axiom in the previous section corresponds to a visit method in a Visitor class [9] 
in charge of transforming the expression. The tool has 6500 lines of Java source code. 
The compiler works by transforming JEAGLE phrases written in a specifi cation fi le into 
equivalent Eagle phrases. A new fi le is produced as the result. 
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The state and aspect class associated to this speeifi cation are generated under the 
directory target Path in a package named monitors. The user must inform where the 
classes mentioned in the speeifi cation are located. The classPath will be appended to 
the ajc (AspectJ compiler) classpath directive which will be called from inside the 
compiler. In addition, the user must inform the name of a method - terminat ionMethod 
- he will call when the program terminates. We track this call and inform Eagle to fi n- 
ish observation. This is necessary to check eventualities. 

5 Conclusion 

We have described a tool that generates observers to monitor temporal properties of 
Java program. The tool and language is named Jeagle and uses Eagle as its base 
logic. The contribution of this work is twofold. First, instrumentation is automated. 
Recall that Eagle does not support instrumentation since it is language-independent 
Second, one can reason about program objects directly in the formula. This makes easier 
to writte object-oriented speeifi cations and also guides program instrumentation. 

Further work includes: (1) enhancing the tool to support additional events and wild- 
cards, (2) developing a visualization tool for the remaining obligation of the formulae, 
and (3) pass vector-clocks as parameters of events in order to tame true concurrency. 
The fi rst allows one collecting data-values from other events in the program and also 
declaring wildcards as actual parameters for the kinds of events described here. This 
should make the defi ration more concise and clear since only the essential variables 
are declared. The second is a tool to support temporal debugging, which has been re- 
ported to be a hard task in temporal speeifi cation [18]. Finally, we should consider a 
true concurrent model where events might happen simultaneously in different proces- 
sors. We believe that by tagging events with vector clocks, as in [17], one can build the 
partial-order from the trace an that could be used as the model to observe. 
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Appendix A: Eagle Syntax and Formal Semantics 

This appendix is a fragment of [3]. 

Syntax 

A specifi cation S consists of a declaration part D and an observer part O. D consists of 
zero or more rule defi nitions R, and 0 consists of zero or more monitor defi nitions M , 
which specify what to be monitored. Rules and monitors are named (A). 

S D O 

D ::= R* 

O ::=M* 

R ( max | min } A(7j x\, — T n x n ) = F 
M mon N — F 

T : Form | primitive type 

F ::= expression | true | false | -F \ F\ A Fz | F\ V Fi \ F\ — ► F 2 | 

OF\OF\F 1 'F 1 \N(F u ...,F n )\x i 

A rule defi nition R is preceded by a keyword indicating whether the interpretation is 
maximal or minimal (which determines the value of a rule application at the boundaries 
of the trace). Parameters are typed, and can either be a formula of type Form, or of a 
primitive type, such as mt, long , float etc.. The body of a rule/monitor is a boolean 
valued formula of the syntactic category Form (with meta- variables F, etc.). Any re- 
cursive call on a rule must be strictly guarded by a temporal operator. The propositions 
of this logic are boolean expressions over an observer state. Formulas are composed 
using standard propositional logic operators together with a next-state operator (OF), 
a previous-state operator (0F), and a concatenation-operator (F\ - F 2 ). Finally, rules 
can be applied and their arguments must be type correct That is, an argument of type 
Form can be any formula, with the restriction that if the argument is an expression, it 
must be of boolean type. An argument of a primitive type must be an expression of that 
type. Arguments can be referred to within the rule body (x z ). 

In what follows, a rule N of the form 

{max|rmn} A (Form /i , . . . ,Form/ m , 7i p\ , . . . , T n p n ) = F, 

where f \ , . . ./ m are arguments of type Form and p\,...p n are arguments of primitive 
type, is written in short as 

I max | min i A (Form f,Tp)=F 

where / and p represent tuples of type Form and T respectively. Without loss of gener- 
ality, in the above rule we assume that all the arguments of type Form appear fi rst. 

Semantics 

The semantics of the logic is defi ned in terms of a satisfaction relation |= between 
execution traces and specifi cations. An execution trace a is a fi nite sequence of program 
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states or = s\sz . . . s„, where \g\ = n is the length of the trace. The i’th state Sj of a 
trace a is denoted by a(i). The term aM denotes the sub- trace of <7 from position i 
to position y, both positions included; if i > j then < 7 ^ denotes the empty trace. In 
the implementation a state is a user defi ned java object that is updated through a user 
provided update OnEvent method for each new event generated by the program. Given 
a trace a and a speeifi cation D O, satisfaction is defi ned as follows: 

a f= DO iff V(mon^ = F) €0.o,l \= D F 

That is, a trace satisfi es a specifi cation if the trace, observed from position 1 (the fi rst 
state), satisfi es each monitored formula. The defi nition of the satisfaction relation j=© 
C ( Trace x nat) x Form , for a set of rule definitions D, is presented below, where 
0 < i < n -b 1 for some trace a = s\sz ...s n . Note that the position of a trace can become 
0 (before the fi rst state) when going backwards, and can become n 4 1 (after the last 
state) when going forwards, both cases causing rule applications to evaluate to either 
true if maximal or false if minimal, without considering the body of the rules at that 


point. 



a , i [=£> expression iff 1 < / < \&\ and evaluate(expression)(o(i)) == true 

(7,i \= D true 



a, i fco false 



a, i \=d “F 

iff i hi) F 

a, 1 (= 2 ) Fi A Fz 

iff (7, i ho F\ and a, i ho F 2 

(7,i PdFi VF 2 

iff c 

f, i ho Fi or a, i ho F? 

gJ\=dF\ — ► F 2 

iff ho F\ implies a,i ho Fz 

cr,/ ho 

iff i < Jcrj and a, i 4 - 1 ho F 

* ho O F 

iff 1 < i and a,i - 1 ho F 

(7,/hoFj Fz 

iff 3 j s.t. i< j < |a| -f 1 and , i \= D F\ and , 1 ho F 2 



r if 1 < i < |a| then: 



(7, i ho F[f 1 — ► F ,p ^ evaluate(P)(c(i))\ 

o,i\= D N(F y P) 

iff < 

where GVfForm f,Tp)=F) € D 



otherwise, if / = 0 or i = |ct| + 1 then: 



rule N is defi ned as max in D 


An expression (a proposition) is evaluated in the current state in case the position i is 
within the trace (1 < i < n). In the boundary cases ( i — 0 and / = n 4 1) a proposition 
evaluates to false. Propositional operators have their standard semantics in all positions. 
A next-time formula evaluates to true if the current position is not beyond the 
last state and F holds in the next position. Dually for the previous-time formula. The 
concatenation formula F\ • Fz is true if the trace a can be split into two sub-traces a = 
CJ 1 O 2 , such that F\ is true on 01 , observed from the current position i, and Fz is true 
on (72 (ignoring <?i, and thereby limiting the scope of past time operators). Applying a 
rule within the trace (positions 1 . . .n) consists of replacing the call with the right-hand 
side of the defi nition, substituting arguments for formal parameters; if an argument is of 
primitive type its evaluation in the current state is substituted for the associated formal 
parameter of the rule, thereby capturing a desired freeze variable semantics. At the 
boundaries (0 and n 4 1) a rule application evaluates to true if and only if it is maximal. 
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Appendix B: Buffer Example 

Source specification 

/* LTL with past and future: */ 

// Future: 

max Always (Term t) = t /\ 8 Always (t) . 

min Eventually (Term t) = t \/ @ Eventually (t) . 

min Until (Term tl,Term t2) = t2 \/ (tl /\ 8 Until (tl, t2) ) . 

// Past: 

max Sofar(Term t) = t /\ # Sofar(t) . 

min Previously (Term t) = t \/ # Previously (t) ♦ 

min Since(Term tl.Term t2) = t2 \/ (tl f\ # Since (tl, t2 ) ) . 

observer BufferObserver { 

classPath = C: /tests/eaglepp 
targetPath = C: /tests/eaglepp 
tenninationMethod = bu f f er examp 1 e. Barrier .end ( ) 

var bufferexample. Buffer b ; 
var Object o ; 
var Object k ; 

mon Ml = Always ( [b?.put(o?)j 

Eventually ( <b.get() returns k?> (o == k) ) ) . 


} 

Generated Specification 

/* LTL with past and future: */ 

// Future: 

max Always ( Term t) = t /\ 8 Always(t) - 

min Eventually (Term t) = t \/ 8 Eventually (t) . 

min Until (Term tl,Term t2) = t2 \/ ( tl / \ 8 Until (tl , t2 ) ) . 

// Past: 

max Sofar(Term t ) = t / \ # Sofar(t) . 

min Previously (Term t) = t \/ # Previously(t) . 

min Since(Term tl ; Term t2) = t2 \/ (tl /\ # Since (tl, t2) ) . 

max r_5 (Object o, Object k) = m_7(htable, o, k) . 

max r_l (Object o, Object b) = Eventually (m_4 (htable, b) /\ rJS{o, getValue (htable, c6) )) 
mon Ml = Always (m_0 (htable) -> r_l (getValue (htable, c2) , getValue (htable , c3) )) . 
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Generated Instrumentation Aspects 

package monitors; 

import eagle. parser. RuieBase; 
import eagle . rhnf . observer ; 
in£>ort eagle . rbmf . EagleState ; 
inport eaglepp.*; 

public aspect BufferObserverAspect { 

3ufferObserverState state = new BufferObserverStateO ; 

Observer observer = 

new Observer (RuieBase. parse { "C: /tests/eaglepp/buf ferexample/buf fer -compiled. spec" ) } ; 
Object lock = new Object (); 

pointcut put. ( buffer exa m ple. Buffer caller , Object argO) : 
target (caller) && args(argO) && 
execution {* buffer example. Buffer, put (Object) ) ; 

before ( buf ferexample . Buffer caller , object argO) returning : 
put. ( caller , argO ){ 
synchronized (lock) { 

MethodCall mcall = new MethoaCalM "caller", caller, 

new EagleMethod { "buf ferexample . Buffer* , "put" , new String [ ] { "Object" } ) ) ; 
mcall . addActualParameter ( "argO " , argO ) ; 
state .setCurrentEvent (mcall ) ; 
state . eventMessage ( ) ; 
observer . handl e { sta te ) ; 

} 

1 

pointcut get. ( buf ferexample. Buffer caller ) ; 

target (caller) && execution (* bufferexample.3uffer.get() ); 

before ( buf ferexample. Buffer caller ) returning (Object result) : 
get- ( caller ) { 
synchronized (lock) { 

MethodReturn mret = new MethodReturn ( caller , new 

EagleMethod { "buf ferexample. Buffer ’ , "get * , new String { ] { } ) , result ) ; 
state.setCurrentEvent (mret) ? 
state . eventMessage ( ) ; 
observer . handle (state ) ; 

} 

} 

pointcut end- () : call {* buff er example. 3arrier.end{ ..)) ; 

before () : end_(){ 
state . terminate ( ) ; 
observer . end ( ) ; 

} 


} 
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Generated Eagle State 


package monitors; 

inport eaglepp . * ; import j ava .util . import j ava . io . * ; 

public class BufferObserver State extends EaglePPState { 

public static boolean m_0 (Hashtable htable) { 

return ( ( (String) getValue (htable, "methodName " } ) J mull && 

( (String) getValue (htable , "methodName" ) ) . equals ( "put " ) ) && 

( ( (String) getValue (htable , * targetType" ) ) 1 mull &6 

( (String) getValue (htable, " targetType ’ ) ) . equals ( 'bufferexample. Buffer" ) ) ; } 

public static boolean m-4 (Hashtable htable, buffer example. Buffer b) { 
return ( ( (String) getValue (htable, "methodName") ) !=null && 

{ (String) getValue (htable, 'methodName" ) ) .equals ('get") ) && 

( ( (String) getValue (htable, "targetType')) >=null && 

( (String) getValue (htable, "targetType") ) . equals ( "buff erexanple.3uffer ' ) ) && 
{ getValue (htable, ’caller") == b );} 

public static boolean (Hashtable htable, Object o, Object k) { 
return (o == k) ; } 

public static final String c2 = ’argO"; 

public static final String c3 = "caller"; 

public static final String c6 = "retObject"; 

private static File logFile = 

new File (" buffer example /errors. BufferObserver State") ; 

private static StringBuffer errorMessages = new StringBuffer () ; 

private static StringBuffer errorWamingMonitors = new StringBufferO; 

private static StringBuffer warningMessages = new StringBufferO; 

public void eventMessage ( ) { 

errorWamingMonitors .append (printEventAsString () +’\n" ) ; 

} 

public void error (String args) { 

errorWamingMoni tors. append ( 'error: " + args + ’ was violated\n" ) ,- 
errorMessages. append (’error: ■ + args + " was violated\n" ) ; 


public void warning (String args) { 

errorWamingMoni tors . append ( 'warning : monitor " + args + " was not validated. \n" ) ; 
warningMessages. append ("warning ; monitor " + args + " was not validated. \n" ) ; 


public static void terminate () { 

System, out .print In ( " " ) ; 

System, out. printing SUMMARY FOR MONITORS') ; 
if { err orMes sages. length ()>0) { 

System, out .print In (errorMessages . toString ( ) ) ; 

} else { 

System. out. printlnf" no violation"); 

3 

if (warningMessages. length ()>0) { 

System, out .print In (warningMessages . toString ( ) ) ; 

} else { 

System. out. printing eventualities validated") ; 

} 

System, out . print In ( * ') ; 

try { 

PrintWriter pwriter = new PrintWriter (new FileWri ter {logFile) ) ; 
pwr iter .print (errorWamingMonitors . toString ( ) ) ; 
pwriter. flush ( ) ; 
pwriter. close () ; 

} catch (IOException ioException) { 

System, err. pr intin ('Could not write to the file."); } } } 
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